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computational  facilities  which  are  appropriate  foi 
instrumentation  in  a  biomedical  research  laboratory.  Th( 
processor  management  system,  called  AMPOS,  provides  tasl 
security  without  requiring  complex  memory  protectioi 
hardware  and  software.  The  system  is  inexpensive,  highly 
modular,  and  uses  standard  off-the-shelf  microprocessoi 
modules.  The  system  does  not  rely  on  multiprogrammming,  s< 
programs,  including  those  for  handling  input  and  output,  cai 
be  written  in  any  of  the  standard  high-level  languages.  Th( 
system  permits  processors  to  be  dedicated  to  i/o  operations, 
so  it  can  provide  a  response  time  of  the  order  of  li 
microseconds  using  standard  microprocessor  components.  Th( 
inter-processor  communication  and  command  language  faciltiei 
are  similar  to  those  of  the  UNIX  system. 


1.0   INTRODUCTION 

Over  the  past  two  decades,  increasing  use  has  been  mad( 
of  computers  in  biomedical  research  laboratories  [see,  fo 
example,  references  CM64,  S64,  BWS76,  SKMS77] .  In  the  las- 
few  years,  increasingly  sophisicated  applications  hav( 
required  that  a  substantial  fraction  of  the  time  needed  t* 
set  up  an  experiment  has  been  devoted  to  developement  of  thi 
necessary  hardware  and  software.  Paradoxically,  thi 
enormous  reduction  in  cost  of  computer  hardware  has  added  t( 
this  problem;  the  availability  of  low-cost  processors  ha; 
tempted  experimenters  into  making  much  greater  use  of  th( 
power  of  computers.  Unfortunately,  most  commerciall: 
available  computer  systems  are  not  appropriate  for  the  need; 
of  a  laboratory:  in  the  extreme  cases  the  user  either  make; 
use  of  a  complex  multiprogramming  system,  pays  a  price  ii 
response  time,  and  is  forced  to  build  special-purpos< 
hardware  interfaces;  or  he  programs  in  assembly  language  oi 
a  bare  machine. 

Recently,  work  at  Rockefeller  University  and  elsewhen 
has  concentrated  on  making  use  of  multiple  processors  ti 
solve  these  problems.  The  system  implemented  by  Silvermai 
[SSL82,  SH82],  for  example,  used  a  number  of  8081 
microprocessors  interfaced  by  a  standard  Multibus  to  provid( 
the  necessary  throughput  for  neurophysiology  experiments. 
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The  system  described  here  is  a  general-purpose 
operating  system  using  standard  hardware  components  which 
provides  an  environment  which  facilitates  implementation  of 
such  applications.   It  has  the  following  major  properties: 

-   it  does  not   use   interrupts   or  multiprogramming; 
each  processor  executes  one  task. 

a  simple  operating  system  provides  powerful 
facilties  while  maintaining  inter-processor 
security. 

Note  that  in  this  paper  we  use   the  word   "task"   to  be 
synonymous  with   "process",   in   order   to  avoid   possible 


confusion  with  "processor 


2  .  0   DESIGN  CONSIDERATIONuS   '  ,  '. "  '  ., :  ,  [ :  ...  ;.;  , 

The  objectives  of  the  design  described  here  were  to 
provide  a  system  which  was  simple  to  use  but  powerful  enough 
to  implement  the  kinds  of  application  programs  required  for 
laboratory  instrumentation.  There  were  two  primary 
objectives.  The  first  was  to  simplify  the  cost  of  software 
construction  by  providing  an  environment  which  encouraged 
programming  in  a  higher-level  language.  The  second  was  to 
replace  the  construction  and  use  of  special-purpose  hardware 
with  software  and  general-purpose  i/o  modules.  These 
primary  objectives  led  to  the  following  secondary 
objectives: 

1.  Fast  response  time.  Some  applications  required 
sampling  at  a  10  microsecond  rate  for  substantial 
periods,  or  continuous  sampling  at  a  somewhat  lower 
rate.  In  general,  the  sampling  rate  was  such  as  to 
exhaust  the  i/o  capacity  of  a  single 
micro-processor,  leaving  no  processing  power  for 
analysis,  computation,  control,  display,  or 
archiving  operations.  This  implied,  then,  that  the 
system  must  permit  processors  to  be  dedicated  to 
i/o  tasks,  while  having  sufficient  communications 
ability  to  pass  along  their  data  to  other 
processors  for  further  processing. 

2.  Fast  inter-processor  communication.  This  included 
at  least  the  ability  to  send  streams  of  data  from 
one  processor  to  another,  with  facility  for 
buffering  to  permit  asynchronous  communication; 
buffering  should  be  done   in  memory,   not   on   the 
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disk. 


3.  General-purpose.  Not  all  tasks  would  necessarily 
be  concerned  with  instrumentation,  but  might 
include  program  construction  and  debugging,  word 
processing,  and  interfacing  to  remote  computer 
systems.  In  general,  we  expected  one  system  to  be 
able  to  provide  for  the  needs  of  a  single 
laboratory  which  might  require  supervision  of  up  to 
(say)  three  experiments,  and  up  to  (say) 
half-a-dozen  terminals. 

4.  Inter-task  security.  Each  task  should  be  secure 
from  accidental  misbehaviour  on  the  part  of  other 
tasks.  In  particular,  it  should  be  possible  to 
debug  i/o  drivers  while  the  system  was  running 
production  programs. 

5.  High-level  language  programming.  Most  programming 
should  be  restricted  to  the  use  of  a  high-level 
language,  except  possibly  for  very  small  highly 
critical  pieces  of  assembly  language  code.  The 
system  should  be  simple  enough  so  that  the  writing 
of  such  programs  could  be  done  by  applications 
programmers  who  are  not  knowledgeable  in  the 
internals  of  the  system.  In  particular,  we  hope  to 
be  able  to  avoid  dealing  with  interrupts. 

6.  A  standard  file  system. 

7.  The  system  should  be  able  to  make  use  of  standard 
off-the-shelf  software  such  as  editors,  compilers, 
assemblers,  and  word-processors. 

8.  The  system  should  be  able  to  make  use  of 
competitively  priced  off-the-shelf  hardware 
modules. 

Note  the  absence  of  a  number  of  properties  commonly  found  on 
such  lists:  in  particular,  we  are  not  too  concerned  with 
the  efficiency  of  the  system  in  terms  of  numbers  of 
instructions  per  second,  or  throughput;  and  we  do  not 
anticipate  the  need  for  rapid  switching  of  processors 
between  tasks.  Thus  much  of  the  current  work  in 
multiprocessor  systems  [SFS77,  SBK77,  081,  GS82,  GLR83 , 
GGKMRS83]  is  not  directly  applicable. 

A  survey  of  typical  applications  suggested  that  the 
above  objectives  could  be  accomplished  with  a 
multi-processor  system  containing  no  more  than  about  a  dozen 
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16-bit  microprocessors  of  the  power  of  a  processor  such  as 
the  Intel  8086.  A  simple  computation  showed  that  for  such  a 
system  the  amount  of  interprocessor  communication  could  be 
handled  by  a  single  bus;  the  word  move  operation  of  a  8  MHz 
8086  moves  a  word  in  about  2  microseconds,  so  8  8086s  doing 
nothing  but  moves  would  only  require  a  16-bit  bus  able  to 
handle  16  bits  every  250  nanoseconds. 

The  other  central  issue  was  the  choice  of 
interprocessor  communication  method.  At  the  time  of  the 
origination  of  this  project,  the  Multibus  was  emerging  as 
the  standard  bus,  with  single-board  computers  containing  a 
processor,  local  memory,  and  i/o  ports  interfaced  to  the  bus 
by  dual-port  memory.  The  processors  on  these  boards  were  in 
general  permitted  to  access  the  bus,  which  could  cause 
problems  since  there  was  no  memory  protection.  Rather  than 
designing  our  own  boards,  we  decided  to  use  these  boards  but 
permit  only  selected  processors  to  access  the  bus;  these 
processors  would  execute  only  system  code,  and  would  be 
responsible  for  all  interprocessor  communication. 

A  second  version  of  AMPOS,  AMPOS/2,  which  will  use  a 
number  of  hierarchical  busses  and  shared  memory  with  memory 
protection  is  in  the  planning  stage. 
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3 . 0   HARDWARE 


The  system  hardware  architecture  consists  of  a  number 
of  processors  with  their  own  private  memory  and  i/o  devices 
interfaced  by  dual-port  memory  (DPM) .  The  processors  are 
divided  into  two  classes,  called  Supervisors  and  Slaves; 
each  Slave  has  a  local  memory,  part  of  which  is  a  DPM.  Each 
Supervisor  has  access  to  the  DPM  of  each  Slave,  but  the 
Slaves  only  have  access  to  their  own  memories.  We 
anticipate  that  most  implementations  will  have  a  single 
Supervisor  and  a  number  of  Slaves;  in  the  remainder  of  this 
paper  we  will  refer  to  the  set  of  Supervisors  simply  as  'the 
Supervisor'.  The  logical  connection  structure  is  as  shown 
in  Figure  1. 
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Figure  1:  Logical  structure  of  the  AMPOS  system. 
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The  hardware  implementation  of  this  architecture  will 
usually  consist  of  a  number  of  processors  and  i/o  devices 
connected  by  a  single  bus;  the  implementation  referred  to 
in  this  report  has  this  structure,  shown  in  Figure  2. 
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Figure  2:  Hardware  structure  of  AMPOS 
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Also  shown  in  Figure  2,  and  playing  an  important 
architectural  role,  are  local  PROMs  in  each  Slave,  and  an 
interrupt  line  from  the  Supervisor  to  each  Slave.  The 
important  properties  of  this  architecture  are  the  following: 

a  Slave  can  be  dedicated  to  servicing  an  i/o  device 

a  Slave  executing  a  (possibly  buggy)  program  cannot 
interfere  with  the  running  of  a  program  in  another 
Slave  except  via  the  Supervisor 

a  Slave  which  runs  wild  can  be  brought  back  under 
control  by  an  interrupt  from  the  Supervisor  which 
is  vectored  into  PROM 


4.0   THE  AMPOS  SYSTEM 

The  AMPOS  processor  management  system  is  a  conceptually 
simple  but  powerful  set  of  control  programs  which  provide 
facilities  which  are  somewhat  similar  to  a  subset  of  those 
of  the  well-known  UNIX  operating  system  [RT78,  C83]. 

A  user  of  AMPOS  is  provided  with  a  terminal,  and  is 
considered  to  'own'  a  number  (possibly  zero)  of  Slave 
processors.  He  can  initiate,  interrupt,  examine,  or 
terminate  tasks  on  these  Slave  processors  using  a  simple 
Terminal  Command  Language  (TCL) .  These  tasks  communicate 
via  serial  (software)  channels,  which  are  called 
'connections',  and  which  can  be  used  for  task-file, 
task-task,  and  task-Supervisor  communication,  without  change 
to  the  task  program.  Tasks  can  spawn  other  tasks  on  other 
Slaves  which  are  owned  by  the  same  user.  Initialisation  of 
connections  can  be  done  either  by  the  task  itself,  or  by  the 
task  which  spawned  it  (including  the  TCL  interpreter).  All 
system  services  required  by  a  Slave  are  requested  by  the 
Slave  writing  into  a  specific  area  of  its  dual-port  memory. 
These  service  requests  are  picked  up  by  the  Supervisor, 
which  returns  status  information  about  the  request. 

A  Slave  processor  is  considered  to  be  in  one  of  two 
modes  by  the  Supervisor;  these  are  called  'active'  and 
'passive'.  When  the  Slave  is  in  'passive'  state  it  is 
constantly  monitoring  a  location  in  its  DPM  for  a  command 
from  the  Supervisor;  such  commands  permit  the  Supervisor  to 
force  the  Slave  to  execute  programs  stored  in  its  PROM,  or 
already  loaded  into  its  RAM.  When  the  Slave  is  in  'active' 
state  the  Supervisor  monitors  its  DPM  for  service  requests. 
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The  facilities  provided  by  AMPOS  thus  comprise  the  TCL 
and  the  set  of  service  requests.  These  are  described  in  the 
following  sections. 


4.1   TCL  Processor  Control  Commands 

The  Terminal  Command  Language  (TCL)  provides  a  simple 
language  for  controlling  the  execution  of  tasks  on  the  Slave 
processors.  A  user  can  execute  a  task  on  any  processor  he 
owns.  The  commands  HIRE  and  FIRE  are  provided  to  request 
and  relinquish  ownership  of  processors  (see  Table  1  for 
details) .  Execution  of  a  task  can  be  done  by  the  EXECF  and 
EXEC  commands,  the  first  specifying  a  file  to  be  loaded,  and 
the  second  a  starting  address  (usually  within  PROM) ;  the 
processor  will  normally  remain  allocated  to  that  task  until 
it  terminates  (or  is  terminated) .  Processors  can  be 
controlled  by  the  INT(errupt) ,  RESUME  and  RESET  commands, 
and  memory  can  be  loaded  by  the  LOAD  command. 

Task  i/o  is  done  on  request  by  the  Supervisor  via 
serial  uni-di rectional  software  channels  called  connections, 
which  can  be  used  to  connect  tasks,  files,  devices,  and  the 
Supervisor.  A  connection  between  two  tasks  is  sometimes 
referred  to  as  a  'pipe';  a  connection  between  the 
Supervisor  and  a  task,  file,  or  device  is  called  a  command 
connection,  since  the  Supervisor  interprets  input  from  such 
a  connection  as  a  stream  of  TCL  commands.  A  connection 
between  a  task  and  a  file  permits  a  task  to  do  file  i/o;  a 
connection  between  a  task  and  a  (terminal)  device  permits 
the  task  to  do  terminal  i/o;  such  i/o  is  mediated  by  the 
Supervisor.  Each  connection  has  a  name,  which  is  used  to 
initiate  (open)  the  connection;  a  name  beginning  with  .PIPE 
is  assumed  to  be  a  pipe  connection,  and  others  are  assumed 
to  be  file  or  device  connections.  Opening  a  connection 
returns  a  small  integer  (its  connection  identifier  or 
conn-id)  which  is  subsequently  used  by  the  task  to  identify 
it.  TCL  permits  the  user  to  specify  a  number  of  connections 
at  task  initiation  time;  these  include  'standard  input', 
'standard  output',  and  'error'  connections;  these 
connections  can  be  assumed  by  the  task  to  be  opened  prior  to 
execution  of  the  task,  and  to  have  the  connection  numbers  0, 
1,  and  8  respectively.  If  not  otherwise  specified, 
connections  0,  1,  and  8  will  default  to  the  connections  used 
by  the  command  connection  which  initiated  the  task  (usually 
the  terminal) . 
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The  TCL  processor  control  cominands  are  given   in   Table 


4.2   TCL  Command  Connection  Commands 

The  TCL  interpreter  is  able  to  process  a  number  of 
command  connections  containing  TCL  commands.  It  processes 
these  in  round-robin  fashion,  one  TCL  command  at  a  time. 
Each  command  connection  has  associated  with  it  a  TCL 
response  connection,  to  which  the  output  of  the  TCL 
interpreter  is  sent.  Usually  a  user  is  provided  initially 
with  one  command  connection  associated  with  his  terminal, 
with  the  terminal  being  the  TCL  response  connection  (see  the 
next  section  for  details  on  how  this  is  done).  The  RUN 
command  (see  Table  2  for  this  and  other  commands  for  dealing 
with  command  connections)  permits  a  user  to  specify  a  file 
of  commands  to  be  executed;  ,in  effect,  this  command  creates 
a  new  command  connection  :and  its  associated  response 
connection. 

Details  of  these  commands  are  given  in  Table  2. 

Table  3  contains  descriptions  of  a  simple  set  of 
commands  which  can  be  used  to  provide  finer  control  within 
command  files.  In  addition,  there  is  a  SHOW  command  which 
permits  a  user  to  determine  the  status  of  the  various 
Supervisor  tables. 
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HIRE  proctype 

This  requests  that  a  Slave  of  type  proctype  be  assigned  to 
the  requesting  user;  the  type  may  be  used,  for  example, 
to  specify  a  Slave  with  a  certain  memory  size,  or  a  Slave 
with  a  certain  i/o  configuration.  The  user  can 
subsequently  use  this  Slave  for  executing  programs.  The 
number  of  the  processor  assigned  is  returned. 

FIRE  pnum 

This  returns  Slave  number  pnum  to  the  pool  of  Slaves;  it 
can  subsequently  only  be  used  if  it  is  first  HIREd. 

EXECF  pnum  filename  {il,i2,...}  {params} 

This  command  initiates  execution  of  the  task  in  filename 
on  processor  pnum;  il,i2,,.,  are  used  to  specify 
non-default  connections.,  The  string  {params}  is  stored  in 
the  (DPM)  memory,  and  can  be  accessed  by  the  program  by  a 
standard  library  routine.  The  non-default  connections  are 
written  in  the  form  i<cn  for  connection  number  i  to  input 
from  connection-name  en,  and  i>cn  for  connection  number  i 
to  output  to  connection-name  en;  if  the  i  is  ommitted  it 
is  assumed  to  be  standard  input  or  standard  output. 

EXEC  pnum  addr  {il,i2,...}  {params} 

This  command  initiates  execution  of  processor  pnum  at 
address  addr,  initialising  connections  il,i2,...  and 
delivering  parameter  string  params.  This  form  is  useful 
for  programs  stored  in  PROM. 

LOAD  pnum  filename 

This  command  loads  the  memory  of  processor  pnum  from  file 
filename. 

INT  pnum 

This  interrupts  processor  pnum  and  forces  it  into  passive 
state;  the  values  of  registers  and  other  state  variables 
are  preserved  in  a  reserved  area  of  Slave  memory.  A 
subsequent  EXECF  will  erase  these  values,  replacing  them 
by  values  which  correspond  to  the  passive  state. 

RESUME  pnum 

This  resumes  the  task  which  was  running  in  processor  pnum 
before  being  interrupted;  note  that  if  an  EXECF  is  issued 
after  an  INT,  RESUME  will  have  no  effect. 

RESET  pnum 

This  reinitialises  processor  pnum,  leaving  it  in  the 
passive  state. 


Table  1:  TCL  Processor  Control  Commands, 
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RUN  cc-name  {>conn-name}  {params} 

This   requests   the   Supervisor   to   establish   a 
connection  named   cc-name   (if   cc-name   is   a  fi 
the  file  being  interpreted  as   a   set 

For   the   commands   in   this   command 
taken  to  be  the  standard  input  connecti 

is  present  it  is  taken  as  the 
(i.e.   the  output  from  the  TCL   interpr 
this   connection) ;    the  default  is  the 


results  in 

commands) . 

cc-name  is 

>conn-name 

connection 

sent  to 

connection  for  the  command  connection  via  which 

was   issued   (often  the  terminal) .   If  params  is 

the  strings  specified  are  used  to  replace  any  refe 

the  names  %0  thru  %99  in  the  command  stream. 


command 
le,  this 
of  TCL 
stream, 
on.  If 
response 
eter  is 
response 
the  RUN 
present, 
rence  to 


WAIT  pnum 

This  command  prevents  further  processing  of  TCL  commands 
from  the  command  connection  it  is  in  until  processor  pnum 
is  passive.  It  is  used  mainly  within  command  files 
executed  by  RUN. 

STOP  cc-id 

This  command  stops  execytion  of  the  commands  in  the 
command  connection  whose  connection  identifier  is  cc-id. 

WAITCC  cc-id 

This  command  halts  processing  of  the  command  connection  in 
which  it  occurs  until  the  command  connection  cc-id 
terminates. 

EXIT  strng 

This  terminates  processing  of  the  command  stream  in  which 
it  occurs;  it  has  no  effect  when  typed  on  the  terminal  if 
there  is  no  other  command  stream  connected  to  the 
terminal.  The  value  strng  is  returned  as  the  value  of  a 
WAIT  command  on  the  command  connection  containing  the 
EXIT. 


Table  2:  TCL  commands  for  dealing  with  command  connections. 
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=  >pnuin 

This  specifies  that  subsequent  input  should  be  sent  to 
processor  pnum  when  pnum  requests  input  from  the  standard 
input  stream.  Input  reverts  to  the  TCL  processor  on  the 
command  =>0.  This  command  is  provided  primarily  to  permit 
uncluttered  communication  between  the  terminal  and  a 
processor,  but  can  also  be  used  to  permit  data  for  a 
program  to  be  included  in  a  file  which  is  RUN. 

variable  =  expression 

This  permits  the  computation  of  simple  integer  or  string 
expressions,  and  their  assignment  to  variables  whose 
values  are  maintained  by  the  TCL  interpreter.  Variables 
with  names  starting  with  $  are  r-ssumed  to  be  local  to  the 
command  connection,  while  variables  with  names  starting 
with  $$  are  assumed  to  be  global  (but  private  to  the 
user)  .  Expressions  may  include  integers,  strings,  local 
and  global  variables,  parameters,  arithmetic  operators, 
integer  comparison  operators,  string  concatenation,  and 
substring  extraction.     -.-.,■  .  -^j- 

variable  =  command 

This  permits  the  value  returned  by  a  command  to  be  stored 
in  a  variable.  If  the  command  is  a  WAIT  command, 
processing  of  the  command  connection  in  which  it  occurs  is 
suspended  until  the  specified  processor  is  passive  or 
until  the  specified  command  connection  terminates;  the 
value  of  WAIT  is  the  value  returned  by  the  exit  request  or 
EXIT  command,  respectively.  In  the  case  of  a  RUN  command, 
the  value  is  the  id-number  of  the  command  connection.  In 
other  cases  the  value  of  the  command  is  just  a  status 
response,  normally  a  small  integer. 

IF  booleanexpr  THEN  statement  ELSE  statement  FI 

This  is  the  usual  conditional  statement.  Nested  IFs  are 
permitted. 

WHILE  booleanexpr  DO  statement  OD 
This  is  the  usual  WHILE-loop. 


Table  3:  TCL  control  statements. 
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conn-id  =  open (conn-name, mode) 

This  request  establishes  a  connection  named  conn-name  in 
the  specified  mode  (input  or  output);  the  conn-name  may 
specify  either  a  file  (or  device)  or  a  pipe;  all 
subsequent  operations  on  this  connection  refer  to  it  by 
conn-id.  Opening  a  non-existent  file  in  write  mode 
creates  a  new  file. 

value  =  status (conn-id) 

This  returns  the  status  of  the  connection  specified  by 
conn-id;  this  will  specify  if  conn-id  is  closed,  or  in 
input  or  output  mode,  and  also  (if  not  closed)  if  it 
refers  to  a  file,  pipe,  or  terminal. 

a-n-bytes  =  read (conn-id, buff-addr, r-n-bytes) 

This  requests  that  up  to  r-n-bytes  bytes  be  read  from 
connection  conn-id  and  stored  in  the  buffer  at  address 
buff-addr;  the  value  of  a-n-bytes  will  be  the  actual 
number  of  bytes  stored. 

a-n-bytes  =  write (conn-id, buff-addr , r-n-bytes) 

This  requests  that  up  to  r-n-bytes  be  written  to 
connection  conn-id  from  the  buffer  at  address  buff-addr; 
the  value  of  a-n-bytes  will  be  the  actual  number  of  bytes 
written. 

seek (conn- id, position) 

This  requests  that  connection  conn-id,  assumed  to  be  a 
random-access  file,  be  positioned  to  the  specified 
position.  The  position  can  be  specified  either  forwards 
or  backwards  relative  to  the  current  position  or  the 
beginning  (or  end)  of  the  file. 

close (conn-id) 

This  terminates  the  association  between  conn-id  and  the 
connection  it  refers  to. 

delete (conn-name) 

This  deletes  connection  conn-name  (assumed  to  be  a  file) . 

exit (msg, count) 

This  indicates  to  the  Supervisor  that  the  Slave  program 
has  finished,  and  that  the  Slave  is  returning  to  the 
passive  state.  If  count  is  non-zero,  msg  is  a  pointer  to 
a  message  of  count  bytes;  otherwise  msg  is  an  integer. 
This  message  (or  integer)  will  be  output  on  the  terminal, 
and  will  be  available  as  the  'status'  of  the  processor. 


Table  4:  Slave  requests 
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4.3   Super-user  Commands 


Initially  the  terminal  connected  to  the  Supervisor  is 
considered  to  be  owned  by  a  'super-user'.  The  super-user 
can  issue  a  special  set  of  commands  which  can  specify  the 
Slaves  and  users  in  the  system.  The  system  is  initialised 
automatically  as  though  the  super-user  had  typed  "RUN 
startup".  This  command  file  specifies  the  initial  Slaves 
and  users.   Slaves  are  specified  by  the  super-user  command: 

ADDSLAVE  proc-type  params 
where  params   specifies  the  memory  addresses  and  other 
parameters  necessary  for  the  Supervisor  to  communicate  with 
the  Slave.   New  users  can  be  logged  in  and  deleted  by 
super-user  commands  of  the  following  form: 

CREATEUSER  user-name  inconn-name 

DELETEUSER  user-name 
CREATEUSER  logs  in  the  user  with   the   specified   name,   and 
provides   him   with  an  initial   command  connection  and 
response.   Normally  the  super-user  will  specify   inconn-name 
as  a  file  with  contents  such  as  the  following: 

RUN  tt3  >tt3 
which  would  set  up  device   tt3   as  the  user's  terminal. 
Alternatively,  if  the  file  contained: 

HIRE  pnum 

EXECF  pnum  command-program  PIPEin  PIPEout 

RUN  PIPEin  >PIPEout 
a  processor  would  be  hired  for  the  new  user  (presumably  with 
a  terminal  as  an  i/o  device) ,  and  start  up  a  program  in  it 
called  command-program;  this  program  would  pass  commands 
from  the  terminal  to  the  command  connection  and  return 
responses  set  up  by  the  following  RUN  command. 


4.4   File,  Pipe,  And  Termination  Requests 

A  Slave  which  is  in  the  active  state  can  issue  a 
service  request  by  adding  it  to  a  queue  of  such  requests 
which  is  stored  in  its  DPM.  Most  of  these  requests  deal 
with  files,  and  are  similar  to  those  of  UNIX;  they  include 
create,  open,  close,  read,  write,  status,  seek,  and  delete 
operations.  In  addition,  an  exit  request  is  provided  to 
permit  a  processor  to  tell  the  Supervisor  it  is  available. 
,The  set  of  requests  is  given  in  Table  4. 

Note  that  the  "fork"  operation  of  UNIX  is  not  provided 
as  a  primitive  request.  However,  it  can  be  simulated  in  any 
Slave  which  has  a  command  connection,  by  writing  a  copy  of 
its  own  memory  to  a  file,  and  using  EXECF.  While  this  is 
not  particularly  efficient,  we  do  not  anticipate  it  being   a 
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common  operation;  the  EXECF  operation  seems  simpler  and 
more  natural  than  "fork"  in  a  multiprocessor  system  with 
separate  memories. 

The  other  main  difference  between  AMPOS  and  other 
operating  systems  is  that  we  have  chosen  to  embed  the 
command  interpreter  in  the  operating  system.  The 
alternative,  adopted  in  UNIX  and  most  other  systems,  is  for 
the  system  to  provide  the  primitives  required  to  implement  a 
command  interpreter,  which  is  then  'just  another  process'. 
While  this  is  an  elegant  solution  for  a  multiprogramming 
system,  where  the  cost  of  a  new  process  is  relatively  small, 
in  a  system  which  is  dedicated  to  the  principle  of  one 
processor  per  process  this  approach  would  have  been  more 
expensive. 


5.0   IMPLEMENTATION         .  ^£.,_   -  ■ 

The  system  described  here  can  be  implemented  using  any 
one  of  a  number  of  possible  sets  of  hardware  modules.  Since 
the  Slave  processors  appear  to  the  Supervisor  as  memories, 
the  main  requirement  is  a  bus  structure  which  will  provide 
address  and  data  lines  which  can  be  used  by  a  single 
processor  to  access  a  number  of  memory  modules;  this 
requirement  is  satisfied  by  nearly  all  the  standard  busses, 
including  the  Unibus,  Q-bus,  S-100  bus.  Multibus,  and 
Versabus.  For  our  initial  implementation  we  chose  the 
Multibus,  mainly  because  there  were  available  commercially  a 
number  of  processor  modules  whose  bus  interface  was  via  a 
dual-port  memory,  and  which  incorporated  a  variety  of  i/o 
interfaces;  such  modules  are  ideal  as  Slaves.  We  use  Intel 
86/30  boards  as  Supervisor  and  Slaves,  as  well  as  a  Slave 
board  of  our  own  design  which  incorporates  an  8086  and  an 
8089  for  additional  i/o  power. 

The  software  for  AMPOS  is  written  in  PL/M.  The 
Supervisor  program  runs  as  a  user  program  within  the  host 
RMX  operating  system  running  on  the  Supervisor  processor; 
this  permitted  us  to  avoid  having  to  deal  with  many  of  the 
details  of  implementation,  including  writing  a  file  system. 
One  result  of  this  is  that  the  AMPOS  system  is  relatively 
easy  to  transport;  any  system  whose  operating  system 
provides  asynchronous  file  operations  (or  multiprogramming) 
could  be  used  as  host. 

A  library  of  routines  is  available  to  facilitate  the 
construction  of  Slave  programs.  These  include  routines 
which  provide  a  higher-level   interface   to   the   facilities 
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provided  by  the  Supervisor  (such  as  i/o  operations) ,  and 
also  routines  to  do  initialisation  and  storage  allocation. 
This  library  currently  supports  the  AMPOS  requests  fairly 
directly,  but  we  also  plan  to  provide  a  Slave  program 
interface  which  looks  like  CP/M ;  this  will  be  a  program 
which  will  accept  CP/M  requests  and  reformulate  them  as 
AMPOS  requests  to  the  Supervisor.  This  will  permit  a  Slave 
to  run  arbitrary  CP/M  programs. 


5.1   Supervisor  Tables 

The  information  kept  by  the  Supervisor  is  in  the  form 
of  a  number  of  tables. 

The  Slave  Table  includes,  for  each  Slave,  its  type,  the 
base  address  and  limit  of  its  DPM,  the  base  address  of  its 
request  queue,  the  queue  size,  the  index  of  the  next  request 
in  the  queue,  the  address  used  by  the  Supervisor  for  forced 
commands,  its  status  (free,  active  or  passive) ,  the  user  who 
owns  it,  its  most  recent  "exit"  message,  a  'suspend'  flag, 
and  a  subtable  specifying  its  connections. 

The  Pipe  Table  contains  information  about  each  open 
pipe.  This  includes  its  name,  its  input  and  output 
connections,  and  the  address  which  specify  its  buffer.  Note 
that  pipes  are  buffered  in  memory,  not  on  disk.  For 
security  the  current  implementation  uses  buffers  in  the 
Supervisor;  additional  speed  could  be  obtained  if  necessary 
by  buffering  in  the  memory  of  the  sending  or  receiving 
Slave.  A  pipe  is  purged  from  the  table  when  it  is  empty  and 
both  of  its  connections  have  been  closed. 

The  Connection  Table  contains  information  about  open 
files,  devices,  and  pipes.  In  the  current  implementation, 
this  contains  the  name,  mode  (input  or  output),  and  status. 
The  file  system  of  the  host  operating  system  handles  most  of 
the  detailed  file  information. 

The  Command-connection  Table  contains  information  about 
each  open  command  connection.  This  includes  input  and 
output  connections,  wait  staus,  and  the  user. 

The  User  Table  contains  information  about  each 
logged-in  user.  This  includes  their  name,  and  the  device  or 
connection  to  be  used  as  their  command  connection  and 
response. 
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5.2   Communication  Areas 


The  DPM  of  each  Slave  acts  as  a  communications  area 
between  Supervisor  and  Slave.  This  is  an  area  which  is 
fixed  in  the  address  space  of  the  Slave,  but  varies  from 
Slave  to  Slave  in  the  address  space  of  the  Supervisor.  The 
Supervisor  polls  this  area  for  each  Slave  which  is  active; 
if  passive,  the  Slave  continually  monitors  a  fixed  location 
for  directives  from  the  Supervisor.  Communication  is  by 
handshaking,  with  the  Slave  writing  into  one  set  of 
locations  and  the  Supervisor  another. 

Requests  from  a  Slave  are  handled  asynchronously  by  the 
Supervisor.  Thus  a  Slave  may  have  a  number  of  outstanding 
requests  at  any  one  time,  in  various  stages  of  completion. 
This  permits  a  Slave  greater  freedom  to  schedule  its 
requests  during  times  when  it  is  not  busy  with  real-time 
operations,  avoiding  the  need  for  dealing  with  interrupts  in 
most  cases. 

Requests  from  a  Slave  are  placed  at  the  end  of  a 
circular  queue  and  removed  from  the  beginning  of  the  queue 
by  the  Supervisor.  The  Supervisor  indicates  it  has  examined 
a  request  by  setting  a  response  byte  in  the  request.  In  the 
case  of  requests  which  will  require  a  delay,  such  as  file 
requests,  the  response  merely  indicates  to  the  Slave  that 
this  location  in  the  queue  is  now  free  and  can  be  reused; 
completion  of  the  request  is  indicated  by  a  'complete'  flag 
outside  the  queue  area. 
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6.0   A  SAMPLE  APPLICATION 


Typical  instrument  requirements  for  laboratory 
applications  can  be  decomposed  into  a  series  of  logical 
subtasks.  AMPOS  provides  a  simple  and  convenient 
environment  in  which  to  construct  such  instruments.  A 
laboratory  experiment  often  includes  such  tasks  as: 

data  acquisition  (A/D  conversion) 

graphical  display  of  data  and  results 

record-keeping 

on-line   statistical   calculations   (averaging  and 
histogram  generation) 

stimulation  (programmed  timing) 

process  control 

A  representative  neurophysiological  experiment  might  start 
with  stimulation  of  the  biological  preparation  and  display 
of  digitized  neuronal  responses.  This  continues  till  the 
user  is  satisfied  that  such  pilot  data  reflects  useful 
information.  The  next  phase  requires  that  the  instrument  be 
reconfigured  so  that  experimental  data  is  acquired, 
displayed,  and  recorded  automatically.  Some  additional 
statistical  processing  might  be  required  simultaneously.  At 
some  later  time,  the  user  might  want  to  review  or  edit  the 
stored  records,  and  to  specify  further  analysis  or 
generation  of  permanent  copy.  These  possibilities  are 
reflected  in  the  diagram  shown  in  Figure  3. 
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Figure  3:  Typical  configurations  for  a  laboratory  instrument. 
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A  primary  consideration  for  the  signal  processing . needs 
inherent  in  a  biomedical  laboratory  environment  is  the 
ability  of  the  system  to  be  reconfigured  to  perform 
different  instrumental  functions.  In  AMPOS,  reconfiguration 
can  be  done  easily  and  rapidly  by  simple  TCL  commands.  From 
the  user's  point  of  view,  an  applications  program  in  AMPOS 
(as  in  UNIX)  can  usually  be  thought  of  as  a  collection  of 
tasks  with  a  number  of  uncommitted  input  and  output 
connections  on  each.  In  AMPOS,  in  addition,  the  user  will 
usually  be  aware  of  the  existence  of  a  number  of  processors, 
each  possibly  with  some  i/o  devices. 

In  AMPOS,  logical  connections  between  elements  (tasks 
or  processors)  can  be  rapidly  and  conveniently  rearranged  so 
that  a  variety  of  task  configurations  are  possible.  For 
example,  to  initiate  the  sequence  for  automatic  data 
acquisition,  (Figure  3  (b) )  the  following  TCL  commands  are 
sufficient: 

procAD  =  HIRE  AD 

procDIS  =  HIRE  DIS 

procSTIM  =  HIRE  STIM 

procSTAT  =  HIRE  STAT 

EXECF  procSTIM  STIMprog 

EXECF  procAD  DATACQprog 

2<PIPEcontrol  3>PIPEdis  4>PIPEstat 

EXECF  procDIS  DISprog 

2<PIPEdis  3>PIPEcontrol  4>datafile 

EXECF  procSTAT  STATPAC 

2<PIPEstat  3>statfile 
The  first  four  commands  hire  the  necessary  processors;  the 
next  four  initiate  the  acquisition  sequence.  For  example, 
the  command,  "EXECF  procAD  ..."  loads  the  program  from  file 
"DATACQprog"  into  the  previously  hired  AD  processor.  It 
initializes  a  pipe  connection  to  the  display  processor 
data  from  connection  3  on  the  AD  processor  is  sent  to  pipe 
"PIPEdis"  —  and  connection  2  of  the  AD  processor  is  used  to 
get  control  parameters  from  the  display  processor.  An 
additional  output  connection  (4)  establishes  a  link  to  the 
statistical  processor.  Standard  input  and  output 
connections  for  the  display  processor  are  used  for  on-line 
control  via  the  terminal. 

A  similar  six  line  TCL  sequence  reconfigures  the 
machine  for  pilot  study  (Figure  3(a))  or  data  review  (Figure 
3(c)).  In  practice  these  command  sequences  would  probably 
be  stored  on  a  file  prior  to  use,  and  the  succinct  "RUN 
autodatacq"  could  be  used  to  initiate  the  sequence  shown 
above. 
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